Internet Protocol (“IP”) telephony or voice over IP (“VoIP”) generally relates to transmission of voice calls or voice information over packet-switched data networks that use IP as a datagram protocol. VoIP systems have recently attracted wide interest because they offer significant advantages over conventional circuit-switched telephone communications. For example, VoIP systems can handle more calls, do not need a separate switched circuit for each call, do not require a specified amount of bandwidth per call, and do not require a large number of geographically distributed central call switching offices, as with the public switched telephone network.
One favored protocol suite for supporting VoIP communications is the H.323 recommendations published by the International Telecommunications Union (ITU). The H.323 recommendations rely on many other supporting protocols to complete operations. For example, recommendation H.235 defines secure authentication of endpoint nodes of a VoIP call.
FIG. 1 is a block diagram that illustrates a model of various VoIP functions in VoIP physical entities, for the purpose of providing more clarity to the general context of packet telephony, and based on J. Vandenameele, “Requirements for the Reference Point (‘N’) between Media Gateway Controller and Media Gateway,” Draft-vandenameele-tiphon-archgway-deomp-00.txt, November 1998.
In the model of FIG. 1, a Gateway 110 comprises a Media Gateway Controller (MGC) 112, Media Gateway (MG) 116, and Signaling Gateway (SG) 114. Gateway 110 is the node in the network that interfaces an IP-based network and the public switched telephony network. It provides two-way, real-time communications interfaces between the IP-based network and the telephony network. Each Gateway supports several end users having telephones.
Generally, Gateway 110 is a node on a local area network (LAN) that communicates with a terminal 108 or other terminals that are attached to other networks. If one of the terminals does not conform to H.323, Gateway 110 performs translation of the transmission formats between the terminals. One Gateway 110 can interwork with another Gateway, for example, when Gateways have different owners or operators. In addition, the Gateway can operate with other ITU switched circuit networks; the PSTN; narrowband ISDN (N-ISDN); and broadband ISDN (B-ISDN, an ATM-based network. The Gateway 110 also can operate as an H.323 Multipoint Control Unit, to support conferencing between three or more terminals and Gateways. Working in conjunction with Gatekeepers 102A, 102B, Gateway 110 can set up and clear calls on the LAN and switched circuit networks.
Media Gateway 116 provides mapping and translation functions between an IP network and the PSTN. For example, Media Gateway 116 might translate speech that is encoded in one manner into speech that is encoded in another manner. Such operations are known as stream conditioning and may include echo cancellation and other functions. For traffic originating from the IP network, packet media termination is performed, since packets do not operate on the telephony side. Therefore, packets are mapped into telephony bearer channels. The opposite operations occur when traffic emanates from the telephony network. Media Gateway 116 is also responsible for support services such as playing announcements, and tone generation as necessary.
Signaling Gateway 114 is responsible for signaling operation and provides, for example, interworking of H.323 and Switching System 7 (SS7) ISUP signaling operations. For example, it might translate an H.323 SETUP message coming from a Gatekeeper 102A, 102B into an SS7 ISUP Initial Address Message that is sent to a telephone central office switch or exchange. Such operations are controlled by Media Gateway Controller 112. Alternatively, such operations may be located in Media Gateway Controller 112.
Media Gateway Controller 112 is the overall controller of the system. It interworks with each Gatekeeper 102A, 102B, and can process H.225 and H.245 messages. It is also responsible for authentication and network security. It also monitors the resources of the overall system, and maintains control of all connections.
Each Gatekeeper 102A, 102B provides address translation and call control services to H.323 endpoints. It is also responsible for bandwidth control, a set of operations that allow endpoints to change their available bandwidth allocations on the LAN. A single Gatekeeper 102A, 102B manages one or more terminals, Gateways, and MCUs in a zone, which is a logical association of such components that may span multiple LANs.
Each Gatekeeper is also a controller and has some of the same responsibilities as the Media Gateway Controller 112, except that it does not control the Signaling Gateway 114 or Media Gateway 116. Its job is to control the H.323 activities on the IP-based network. Back End 104 may be used by Gateway 110 and its elements, and Gatekeepers 102A, 102B, to carry out support functions such as billing, database management, routing, and address resolution.
Reference interface E.a is the interface for telephony user links, such as lines and trunks. Reference interface E.b is the interface for SS7 signaling links.
Terminal 108 is an end-user device that is used to place or receive a call. Under H.323, a terminal is an end-user device that provides real-time, two-way voice, video, or data communications with another H.323 terminal. The terminal can also communicate with a Gateway 110 or a Multipoint Control Unit (MCU). The terminal does not need to be configured to support all services contemplated under H.323 and the specification does not require the terminal to be capable of multiple services.
ITU-T Recommendation H.235 of February, 1998 describes security and encryption for H-series multimedia terminals, including H.323 and other H.245-based terminals. Section 10.3.3 of H.235 specifies that data structures carrying encrypted information, called “cryptoTokens,” can be used to allow endpoints to authenticate themselves to one another. However the token field of the cryptoEPPwdHash part of the cryptoH323Token and the cryptoGKPwdHash part is defined such that the authenticating endpoint is required to have access to the password associated with the endpoint that is being authenticated. The token field is calculated as follows:token=[[[ . . . , timeStamp, generalID, password]ASN.1 encoded]MD5 Hash]The “generalID” value is the to-be-authenticated endpoint's alias and the “password” is its associated password. The timestamp and the general ID are transmitted unencrypted (“in the clear”), along with the token. The authenticating endpoint uses the generalID value to look up its associated password, and performs the calculation set forth above to generate a token. If the received token matches the one generated locally, then the sender of the token has been successfully authenticated.
Given the many-to-one relationship between H.323 Gateways and H.323 Gatekeepers, a gatekeeper would have to maintain a large local database of gateway IDs and passwords, sufficient to authenticate all users of the system, or have some way to securely retrieve such gateway IDs and passwords in order to use cryptoTokens to authenticate gateways. The database potentially could require storage of Gateway identifiers, user account numbers, passwords, and PIN numbers. Since a Gatekeeper is responsible to interoperate with any number of Gateways within its zone, such a database potentially could be large. This is undesirable for numerous reasons; it requires a large amount of potential storage and represents a source of potential security leaks. Further, as the database size grows, the time required to authenticate a particular user increases. The problem is compounded if in addition it is desired for gateway users to be authenticated in the same way. Router or other embedded system based gatekeepers that don't have local database support are left with having to retrieve the needed information, possibly over insecure links.
Known network elements provide authentication mechanisms that may be useful in this context. For example, many networks rely on authentication servers with well-established authentication protocols in order to authenticate users before granting the users access to the network. An example of such authentication servers is a Remote Access Dial-In User (RADIUS) server that supports Challenge Handshake Authentication Protocol (CHAP). In conventional operation, a user logs in to a system, and the RADIUS server sends a random Challenge string. At a user endpoint, the Challenge string is used to calculate a Response or answer message. The RADIUS server determines whether the Response matches the Challenge based on a secure internal algorithm.
Based on the foregoing, there is a clear need for an improved way to authenticate endpoints under H.323.
In particular, for routers and embedded system gatekeepers, there is a need for a way to authenticate gateways and their users without the database management problem.
There is also a need for a way to carry out authentication among endpoints using existing technology, such as RADIUS servers, thereby moving the most significant processing burden involved in authentication to the RADIUS server.